Allowing parameter-level decorators at method level was an intentional decision we made early on, so that we can support the following pattern:

class MyController() {
  @param.body('todo', TodoSchema) {
  async createTodo(...args) {
   return await this.todoRepo.create(...args);
  }   
}

As long as the example above keeps working (we keep it covered by our automated tests), I think the changes you are proposing here are a matter of subjective preference and can be landed if we all agree that's the style we want to promote.

I personally like more the old (method-level) style:

• All REST decorators are specified in a single place (before the method)
• The method signature is easier to read, because it's not cluttered by decorators

Compare:

// now
@get('/todo/{id}')
@param.path.number('id')
@param.query.boolean('items')
async findTodoById(id: number, items?: boolean): Promise<Todo> {
  // ...
}

// proposed
@get('/todo/{id}')
async findTodoById(
  @param.path.number('id') id: number, 
  @param.query.boolean('items') items?: boolean,
): Promise<Todo> {
  // ...
}

Having said that, the difference is not super important to me, so if there are more people in favor of your proposed style, then I am ok with that.

@strongloop/sq-lb-apex @strongloop/loopback-next opinions?

@bajtos I think the method level decorators promote a top-down approach since the intended use for them seems to be is to have the users provide a schema, but I'm not so sure anymore. Currently, type inference is only possible with the parameter-level decorators and it seems like that's what we should promote since it is better for the UX, but I think it's also possible to infer the parameter types through method-level decorators, so I guess the change isn't strictly needed if we plan on adding in support for method-level decorators' parameter type inferrence.

Update: the following old comment is not a concern now. The new decorator requestBody allows overriding the generated schema by decorator's input.

@bajtos Interesting, I also come across a decision making about "method decorator" or "parameter decorator", or both.

The benefit of "parameter decorator" is it guarantees the consistency between openapi spec and controller function's inputs. But it may also have limitation:
Take the openapi3 requestBody spec as an example, one requestBody can have multiple content-type, if they don't share a common schema, we need to apply @param.body, which will equivalent to @requestBody in openapi3, to multiple parameters, but ideally one function only has one input for body data.

I started a discussion in #753 (comment)
And post my concern in #753 (comment)

Personally I love the parameter decorator, even given my concern above, I would still like to try adjust the decorator code to support the multiple contents.